I don't know if this is something you're interested in, but it's the direction in which I plan to take my personal fork of ldtk-haxe-api

The Problem

I find it oddly hard to write generic code for ldtk, that is useful in multiple projects or for multiple types that are built via macros. The use of macros are - I'll admit - a fucking lifesaver and make starting new projects a breeze, but I find myself copying and pasting the same utilizing code from project to project (and sometimes multiple times in the same project) and changing the class names just to get the same fields that are in every tileset or tile layer but not in the respective base classes

The Solution

Put those fields and functions in the base classes and use type params to make it easy to pass them around to generic utils without needing to know the specific generated class for each project.

The Changes

• Rename Tileset to TypedTileset<TTag:EnumValue>, and add a untyped Tileset typedef
• Add hasTag and getAllTags to the base class, override getAllTags in the built types, (I could also make Tileset an abstract class, but that seemed more risky, as it's a recent haxe feature, and maybe not a backward compatible change)
• Rename Layer_Tiles to TypedLayer_Tiles<TTag:EnumValue> and add a untyped Layer_Tiles typedef. In my tools I'm using this for `@:privateAccess layer.untypedTileset
• Add tileset field to Layer_Tiles
• Built extensions of Tileset and Layer_Tiles now extend their typed versions

Another option, rather than having the old type as a typedef of the new typed class, we could have the typed class extend the untyped version with the newly added typed fields (just thought of this, might explore as it may resolve some covariance issues)

The future

I think there many other places that would benefit from having more generic type options, I can make an issue listing them out if there's any interest